Clustering of computer systems is becoming an increasingly popular way for enterprises and large businesses to ensure greater availability to multiple users. Different types of clusters have evolved, including high availability (HA) clusters, high performance clusters, load balanced clusters, and the like. Examples of clustering systems include the Veritas™ Cluster Server, HP Serviceguard, and/or Microsoft Cluster Server. High Availability clusters are a class of tightly coupled distributed systems that provide high availability for applications typically by using hardware redundancy to recover from single points of failure. HA clusters typically include multiple nodes that interact with each other to provide users with various applications and system resources as a single entity. Each node typically runs a local operating system kernel and a portion of a cluster framework.
In the event of a hardware or software failure, an HA cluster automatically restarts applications on the same node or “fails over” (i.e., restarts applications on a different node) the applications in order to keep applications available to clients of the cluster. Conventionally, the cluster software is responsible for starting/restarting applications on one or more nodes of the cluster.
Individual software components on an HA cluster may be configured as resources or services. A resource or service might be any component that is capable of readily being relocated from one node to another node. The term “resource” is used herein to refer to a resource or a service. Typical examples of resources include disk volumes, network addresses, software processes, or the like. A group of resources or services that run together on the same node is known as a resource group.
An HA cluster typically employs an API to enable communication between a resource and other components. One API includes a callback mechanism, in which a resource or service registers one or more callback functions to be invoked when communication with or control of the component is desired.
Often a resource or service might require the services of another resource or service. For example, a software application might require a disk volume. Typically, a cluster includes a mechanism for maintaining information regarding dependencies among resources or services. A cluster may use this information, for example, to start a first service prior to starting another service that is dependent on the first, or to shut down the second, dependent service prior to shutting down the first service.
A cluster may require resources or services that are external to the cluster. This may require techniques or mechanisms that differ from those used when employing resources or services of the cluster. It is with respect to this consideration and others that the current invention is directed.